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 Motivation- . 
e 2016 - I heard of a new gadget: smart my 
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el only need the light when I'm physically in the room Z 


© Why would | need an app to toggle the switch in the entrance? 
e 2018 - More than 400,000 UK households use smart lightbulbs 
© OK, there is surely some security problem in it 


& The response: Don't be silly, it's only a lightbulb, it's fine 


& A Lightbulb Worm? (@colinoflynn & 


e lot Goes Nuclear: Creating a Zigbee Chain Re 
& Authors: Eyal Ronen, Colin O'Flynn, Adi Shamir and Achi-Or Weingarten 
e Website: https://eyalro.net/project i orm.htmi 
e War-flying demo: https://youtu.be/Ed1OjAuRARU 

e With @eyalr0’s help, going to continue their research 


So, wh at did they find? 
’ J am. 


e Attackers can remotely "steal" a lightbulb fr i a given ZigBee 


network, and force it to join their own network 


Attackers that share the same ZigBee network with a target 


lightbulb can send a malicious Firmware update to it 


© Even a regular lightbulb can be used to “steal” other lightbulbs 


So, what did they find? 
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e Attackers can remotely "steal" a lightbulb fr a a given ZigBee 


network, and force it to join their own network 


Attackers that share the same ZigBee network with a target 


lightbulb can send a malicious Firmware update to it 
© Even a regular lightbul cathe sed to "steal" other lightbulbs 


Fixed by the vendor 
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New Goal: Infiltrate the the ab 
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ZigBee 107 
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e A suite of high level protocols for close EN networks 


e IEEE 802.15.4-based specification 
© low range / power radio (Not to be confused with IEEE 802.11 - WiFi) 


© Maximal Transmission Unit (MTU) of only 127 bytes! 


e ZigBee has a full network stack of its own 
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ZigBee Cluster 
Library (ZCL) 


N 
ZigBee Device 
Levels 5+ Profile (ZDP) 
Levels 4 
Levels 3 
Levels 1-2 


IEEE 802.15.4 


Meet Our RIN 


ij : 
e Philips Hue smart lighting (now under “in V V V 
© Signify controls ~ 31% of the market in the Wi H e 


© We are going to focus specifically on the bridge 


© Connected to both ZigBee (radio) and Ethernet 


© Specifically, hardware version v2 
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ZigBee "Modem" WE 279 TIESA 
ATSAMR21E18E 


e Once finished, we get a root SSH connection & 
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“... (the bridge) Is 
using a single 

huge process that 
does everything” 


— ipbri dge K 


e A single process that acts as the "brain": 
© Parsing incoming ZigBee messages 
& Maintaining protocol state machines 
E M 


© ipbridge runs with root privileges © 


© This is going to be the target process for our research 
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~ Slow start + 
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e Due to technical issues | couldn't root the brid je 
© Didn't have the right equipment y 
& And the package we ordered got delayed (snail mail) & 
& Meanwhile, started working on an old firmware version 


& Version from the original research (2016-2017) 


NS ipbriage 


W aw AN 


& At First glance, we saw something odd 


The code expects strings in the incoming N.W 


E „word aConnection 
© The MTU is 127 bytes E 
„word © 
„word off 53FF48 
© The message should use bits 775 -24 
„word 2 
„word 8e 


' 1 „word off 53FE86 
e What is going on here? iei 
„word aZcl 
„word 2 
„word EI zcl main handler % 
i $a8 - input buffer (char *) 


# fal - string name (cmd descriptor ?) 
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Things get complicated 

“i J Ac NN 

e We forgot about the ZigBee "Modem" 
y 


e Uses Atmel BitCloud SDK to parse incoming mess 
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Acts as a co-processor that handles the ZigBee lower network layers 


& It converts the parsed messages to textual form and sends them 


over serial to the main CPU 


© We don't have the firmware for it - a black-box... 


Living alongside a black-box = = 
& The modem reduces the attack surface on P b CPU e [äi 


© Complex parsing is offloaded to the Modem / 
© We don't fully control messages sent to the main CPU 
& Adds a huge uncertainty to everything we find 


© Maybe the modem checks it? 


e Let's add it to the list of issues, and hope for the best ... 


Vulnerability Attempt #1 
W d n N 
e The ZigBee Cluster Library (ZCL) manages c A'U 
rface 
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e Offers a READ ATTRIBUTE / WRITE ATTRIBUTE i 


© Supports multiple types: E ZCL BOOL (0x10) 
E ZCL UINT8 (0x20) 


E ZCL ARRAY (0x48) 
E ZCL UINT32 (0x23) 


© Hmm, variable-sized data type in an embedded device 


e This looks promising 


B1A0 
B1A4 
B1A8 
BIAC 
B1BO 
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Bice 
Bic4 
B1C8 
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# Store Worc 
+ Store Byl 


jal EI malloc „with mutex # Jump And Link 
li '—' # buffer of @x2B bytes (43 bytes) 
move $ 
move 
13 $a2, Ox2B # '+' # Load Immediate 
jal memset + memset(pBuffer, ©, sizeof(buffer) = @x2B) 
SW $v0, zcl attribute.data or pData($s1) # Store Word 
lw $a0, zcl attribute.data or C # Load Word 
lbu $a1, zcl attribute ang 
E EI-DBG: EL (1- BTE memcpy into a 
+ EI-DBG: fixed size 0x2B heap buffer. 
# EI-DBG: ==> Heap Buffer Overflow :) 
move $a2, $s3 
SW $s0, Ox38+var 28($sp) # Store Word 
jal EI zcl read blob| # Jump And Link 


Vulnera bility Attempt #1 


«X x €" 


CMS. NN 


e It isn't a vulnerability until we have a PoC W igger it 

© We don't have the latest firmware yet 

© The Modem could block large ZCL arrays 

© We don't have radio equipment to transmit the attack and test it 
e Finally, the package arrived 


o We can root the bridge and extract the latest firmware 


\ 
ing! 
wa this firmware 


N 
Ox504-p or($sp) 


1256 lw 

1258 jal 

125C lu $a6, Ox50+ppData($sp) contains symbols! 
'L25E move data type, $vO — ff length of the string 

1260 li $v@, 9x10 


(1262 addiu ape data -type, 1 # parue += 1 n IOF) 
11264 SW 7 a va 


‘1266 jal E 
'126A sh a type, _attr e(output- 

1260 move $a0, $ve z aea sacs for the string 
'126E li $a1, O 

1276 move $a2, data type 

1272 jal EI memset 

11276 sw $v@, zcl attribute value.pData(output struct) 
11278 lw $v1, @x50+pIsError($sp) 

(127A lw $a0, zcl attribute value.pData(output struct) 
;127C lw $a2, Ox50+ppData($sp) 

;127E lw $a3, Ox50+pLength($sp) 

11280 sw $v1, Ox50+var 40($sp) 


'1282 jal UTIL Fetch Buffer 


Nope, ~ 4 PAS 


G SN 
& Latest firmware version dropped support fo fo $6 Arrays 


e Supports ZCL Strings instead j 


e Sadly for us, strings are parsed correctly 
& Time to search for other vulnerabilities 


& Covered most of the firmware, and found ageing... 


Nope, No Vulnera bility 
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e Latest firmware version dropped support P Arrays 
e Supports ZCL Strings instead 


e Sadly for us, strings are parsed correctly 
e Time to search for other vulnerabilities 
© Covered most of the firmware, and found nothing... 


& Who handles the incoming ZCL strings later on? 
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Vulnerability Attempt 42 — 


LOAD:0052735C loc 52735C: — 
OAD:0052735C lw $vO. cmd dispatch attribute struct.at 
nee 2735 [empl $00, 0x p S. 
LOAD:00527360 btnez oc 527380 
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LOAD: 00527362 jal 

LOAD:00527366 li $a0, Ox2B # |+' 

LOAD: 00527368 move $a0, $v0 

LOAD :0052736A li $a1, 9 

LOAD:0052736C li $a2, Ox2B # '+' 

LOAD: 0052736E sw $v@, Ox1C($s1) 

LOAD :00527370 jal EI memset 

LOAD: 00527374 sw $v@, Ox38+var 18($sp) 

LOAD: 00527376 lw $ad, Ox38+var 18($sp 

LOAD: 00527378 lw $a1, cmd dispatch attribute struct.attribute.pData(attribute struct) 
LOAD:0052737A jal EI memcpy 

LOAD: 0052737E lhu $a2, cmd dispatch attribute struct.attribute.size(attribute struct 
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Vulnerability Attempt #2 
AD : 0052735C 
):0052735C maja — 
OAD: 0052735C md dispatch attribute struct.at 
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PEN —— $a2, @x50+pIsError($sp) 

oap oo 1258 jal UTIL Fetch uint8 

LOAD:005125C lw $a0, Ox50-*ppData($sp) 

ne data type, $vO # length of the 

L0AD: 005/1260 

LOAD:005;1262 ad $a0, data type, 1 # length += 

moon 1264 SW $v@, zcl attribute value(output s 

LOAD: 060» 1266 jal OSA | MEMORY | Malloc " malloc(n*1) A(attribute_ struct) 
LOAD: 005273 /4" Jan ri merhcpy 

LOAD: 0052737E lhu $a2, cmd dispatch attribute struct.attribute.size(attribute struct 


Vulnerability jw H2 


© Someone forgot to finish the migration i d to String 
e Should have been marked with OxOF for String 
o However, internally they are still marked with 0x10 for Array 

e The original vulnerability still exists in the code © 
& Just buried a bit deeper, that's all 


e Time to start transmitting ZigBee messages 
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Playing a around with ZigBee 


& Like the previous research, m to use m -XPRO 
e Support sending/receiving ZigBee IEEE 802.15.4 radio frames 
Should be computationally equivalent to a lightbulb 

Timing constraints dictate we use C code executed on the board 


© Our entire ZigBee code + exploit will be implemented in C 


The vulnerable Flow is accessible during Commissioning 
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COM 


© The process of pairing and associating ane ghoul 
& Classic Commissioning 


Touchlink Commissioning 


e The Philips Hue app initiates Classic Commissioning 
e In theory, the ZigBee specs explains the entire process 


e In practice, a lot of room for vendors to do as they wish 


analyzing the protocol 


No documented flow - What message is ei be sent? When? 
e Can't sniff a full conversation - Too many messages, sent too fast... 


© We need the (Broadcast) transport crypto key, how do we get it? 


© Not the first to tackle this issue - https://Deeveeone.com/?p-166 


e Analysis & implementation took a lot of effort, but it worked! 


© Hue color light 1 


/ | 


7 Hue color light 1 
| Hue color light 1 


© No documented f Eo be sent? When? 
i 
1 e Classic bulb 
e Can't sniff a full c ^" T s, sent too fast... 
e We need the Eras v do we get it? 
o Not the first tota sw. 1568. r30456 /?p-166 
& Analysis & implen iit worked! 


We open sourced our full .pcap of a classic commissioning: 
C ithub.com/CheckPointSW/Cyber-Research/tree/master/Vulnerability/Smart Lightbulbs 


a Thus Far Far 


e Without user interaction, the bridge won vr Ra new lightbulbs 
e We have ~1 minute to commission as many lightbulbs as we want 


© The user will see the lightbulb in the app only after the “ZCL phase" 


Good News: Managed to trigger the vulnerability during the ZCL 


phase! 


Lessons TF 
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© Without user interaction, the bride lbs 


e We have ~1 minute to commission as 

© The user will see the lightbulb in the ay A | 
© Good News: Managed to trigger the ability during the ZCL 

phase! 

© No state machine check — send whatever response you like 


© However, can only trigger the vulnerability during this phase 
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e We have a linear buffer overflow over the N 


© Our buffer size is limited to 70 controllable bytes 


© ZCL is quite high in the ZigBee stack, and the initial MTU is only 127 bytes 
& We don't have any byte constraints on our payload 


& The destination buffer is allocated on the heap 


© Fixed size of 0x2B (43) bytes 


EM x, d > 


NN 
& The bridge uses uClibc — (old) embeddec EU 


© Chosen heap implementation is malloc-standard (dlmalloc) 
e Much like glibc, but with less sanity checks 
© All of our free buffers will Fall into the range of the fastbins 


© Bin for each buffer size (multiple of 8) starting From 0x10 


© Each bin contains a singly-linked list of free()ed buffers 


Code snippet 


From free(): 


/ devi null fastbin 
Ew N 


if ((unsigned long)(size) <= (unsigned long)(av-»max fast)) 


{ 


set_fastchunks(av); 

// EI-DBG: Who checks that size >= 8x18? 

// EI_DBG: Lower size will get us indices -1 and -2 
fb = &(av->fastbins[fastbin_index(size)]); 

p->fd = *fb; 

*fb = p; 


/* offset 2 to use otherwise unindexable first 2 bins */ 
define fastbin index(sz) ((((unsigned int)(sz)) >> 3) - 2) 


/d S ull Fastbin 


struct malloc state i 
Code 


/* The maximum chunk size to be eligible for fastbin */ 
from size t max fast;  /* low 2 bits used as flags */ 


/* Fastbins */ 
mfastbinptr fastbins[NFASTBINS]; 


e Index -1 > Store the buffer on top max fast - too risky 


e Index -2 > Store the buffer on an unused variable, 


creating a ghost linked list acting as /dev/null 


Heap Overflow Plan 


m User's data buffer msn User's free buffer 


Heap Ove rFlow Plan 
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Goal: Confuse malloc() to "allocate" a buffer at an 
arbitrary address 


Hea So nindsths Legy 


© Overflowed a free fastbin buffer? — Bingo! thi is what we aim at 
e Overflowed a used buffer? - When free()ed J. go to /dev/null 
© Overflowed a used buffer that lives Forever? — oh well 

© Overflowed a free large buffer? — We will probably crash soon © 


e If done correctly, we will get the desired Malloc-Where 


Heap shaping Strategy 


aw 
e Malloc-Where will grant us the ability to B i the GOT 


e Global-Offset-Table 


© A table full of function pointers used to execute library functions 
e The GOT is at a fixed address & 
e The modified fptr will jump to our shellcode* 


e *Sounds easy on paper, way harder in real life 


SIEN We 
Shellcode: 
Theory vs Reality 


Location, Location, Location 
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e We need to store a binary shellcode i in a Fixed lobal address 
The problem - we get textual messages from the ZigBee Modem 
Found only one good candidate for such a buffer 

© The ZigBee "phone book" 


© Array of ZigBee addresses seen / advertised thus far 


& Can hold up to 65 records of 16 bytes each (~ 1KB) 


The “Neighbor Record" 


e Bytes 0x00-0x08: Extended network addre Fully controlled. 
Bytes 0x09-0x0A: Short network address - Fully controlled. 
© Bytes 0x0A-0x10: Misc fields - Uncontrolled. 

e Oh, and about that 


e The bridge is unstable when it gets » 20 records 


& This is going to be a very small shellcode 


“Initial plan +. 
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© It seems infeasible to restore the execution Flow 
e Instead, the shellcode will patch the binary with a backdoor 
e After a crash, the daemon will restart with our backdoor 


© Problem: 


© The patch and the file-path don't fit in 10 consecutive bytes (each) 


al" Shellcode 
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& Use the 10 consecutive bytes per record > a decoder 


"Ide 


e In mips16 a jump to the next record only costs us 2 bytes 


e Problems: 
o We need to clear the cache before jumping to the unpacked shellcode 
© If we sleep(), the watchdog kills the process 


© We don't have enough records to silence the watchdog 


"Bold" Shellcode 


JL X 
© We will restore the execution low we M choice 


e This means we mprotect() and install the backdoor in RAM! 


© A Few days, and one hand-crafted shellcode later: 
© The shellcode fully restores the execution (GOT, heap, everything) 


© The shellcode costs us 16 records — well in budget 


Connecting the dots 


& The backdoor shellcode gives us an Arbitrary- 


© Our exploit fakes a “legitimate” lightbulb that will leverage it 


e Used the Arbitrary-Write to write Scout's loader to memory 


Upon execution, Scout loaded the Full payload - EternalBlue 


61568 /usr/sbin/ipbridge -p /home/ipbridge/var -z /dev/ttyzZzigbee 
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© Time for a demo © 


| 1 
' youtube.com/watch?v=4CWUODA i 


Coordinated Disclosure 
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e Vulnerability was reported to Signify on MÀ Nov 2019 


& The vendor confirmed the vulnerability on the same day! (impressive) 


e Signify issued a patch via an automatic update on Jan 2020 


© Full details & Advisory in our blog post- CVE-2020-6007: 


& All products should have received the update by now 


Conclusions. 
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e Even with an MTU of 127 bytes, ZigBee m i exploitable 


& Security mitigations only work when they are on-by-default 
© Static binary For ipbridge, no stack canaries, writable GOT, ... 


© ASLR for heap, stack and loaded libraries (thank you Linux) 


e Smart devices are becoming popular by the minute, 


and yet, we can't even trust our lightbulb... 
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© Special thanks to everyone that helped in i research possible 


Eyal Ronen ((GeyalrO) - Research idea & active guidance 

© Colin O'Flynn (@colinoflynn) - Detailed writeups on rooting the bridge 
© Peter — Publishing the ZigBee transport keys for the lightbulb 

Yaron Itkin — For the crucial hardware support along the way 


e Thanks little brother & 


e And finally, to the entire cp<lÊl> team for their support 
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